In this report we present a framework to support the construction of controlling tools for session languages. The tools should be able to respond to errors detected on established sessions such as physical problems like the drop of a connection or logical issues like the inconsistency of the data received (data that do not respect logical constraints that could not have been expressed by the type).

The framework is independent from the specific session language and therefore could be easily adapt to different  scenarios. For simplicity we choose to work with a synchronous session language.

We start with the standard example of a client/server scenario. In this example we have two actors: the client and the server both with their own code that manages the interaction between the two actors. We imagine that each actor of the system is implemented in a separate location or \emph{configuration} that contains the code, the controlling system and a state. Configurations are denoted with $\tuplem{l}{P}{S}$, where $P$ represents both the code and the controlling system and $S$ is the state.
More in detail, $P$ encodes on one side how to achieve a certain task, possibly by interacting with several actors: i.e., in the case of a holiday booking service, several servers need to be contacted in order to take care of all aspects related to the holiday (traveling part, hosting part, special services etc.).  
On the other side, the controlling system is a handler that depending on some external or internal signals takes some decisions on the behavior of the configuration. We will refer to the controlling system as the manager of the configuration. The manager is able to interact with an unspecified environment. The environment can send messages that refers  both to internal (to the configuration) and to external physical events. Based on the information collected from the environment and on the internal state of the configuration the manager will take a certain sequence of actions.
The state of a configuration $S$ is given by the a number of records, each record is associated to an establish connection and we store the information on the current type of the session together with a queue of special messages that are read by the manager.   
As we choose to work with synchronous sessions, our records are simple, but they can be easily adapted to handle more complicate scenarios (as for instance in \cite{NobukoDimitrios}).
Also depending on how complicate is the task of the manager additional data structure can be added to the configuration. 

We could imagine that the environment sends special signals whenever something unexpected happens. For instance, it could happen that the connection between two actors has drop, it is therefore the duty of the manager to decide what to do. The easiest policy would be to interrupt and remove all the established communications of the configuration.
This is obviously a very restrictive and drastic decision as we are influencing also sessions that could have been independent from the session in which the problem was detected. 
Nevertheless, in order to treat more complex scenarios we need to introduce data structures that store information on how sessions depend from each other and information that allows to implement rollback policies, thus giving the possibility to the manager to restore previous/old configurations.

For this reason we add to configurations a new data structure that we call memory $\tuple{l}{P}{S}{M}$. $M$ is a tree of objects, each of these objects represents a recovering point: i.e. a portion of code, with its associate state. Intuitively, we create a node in the tree every time we establish a new session, thus the tree structure represents the dependencies between sessions and each node stores the information needed to restart the computation from that point in case something unexpected happens.
It is the manager that depending on the message received, on the state and thanks to the information that can be retrieved from the memory implements the proper strategy.

We mention several times that the manager can take decision depending on the state of the configuration. To this aim, we are introducing a choice operator (following the approach in \cite{}) that by testing the current type of the session bases its decision not only on external messages but also on the specific nature of the session. 

\begin{itemize}
 \item Manager
\item configuration with process and state
\item action of the manager
\item stop
\item migrate (?)
\item typecase
\item aggiungere ripristino e compensazioni
\item servono le memorie
\item gestione memorie e rollback
\item rollback
\end{itemize}
 

